Thanks for the nice discussion @nguidotti and congratulations on the nice performance improvement with this PR. I'm removing the Request changes so that you can merge when ready.

A couple suggestions:

1. It sounds like the only reason node_queue_t exposes lock and unlock is to allow a worker to steal a node from another. It would probably be better to add a method like node_queue_t::steal_from_victim(node_queue_t& victim) and handle the locking and unlocking of both queues directly in this method. That would allow you to not expose node_queue_t::lock/unlock and make it so that people touching the branch and bound code did not need to be concerned about correctly locking and unlocking the node queue. Inside steal_from_victim you can avoid deadlocks by acquiring the lock on the thief and the victim in sorted order according to their worker id (so this might need to be node_queue_t::steal_from_victim(i_t thief_id, i_t victim_id, node_queue_t& victim))

Ideally, stealing a node is an atomic operation, so that the node is always either in one queue or another, and thus the node's lower bound is always considered. If you are able to make it an atomic operation you can avoid the need to track the lower bound associated with the node separately (which may be prone to bugs).

Also, if diving needs to copy a node from the node queue, and that cannot happen while stealing, you can add a method node_queue_t::copy_node that acquires mutex_ internally.

Maybe you are able to make the above changes before merging.

2. Longer term, I think it's worth defining the correct abstractions and data structures to make managing the lower bound simpler. A heap is already the ideal data structure for managing the lower bound, since it inherently takes the lower bound over the nodes it contains. I think we've introduced a lot of book-keeping and other data structures to manage nodes and lower bounds outside the heap. This is likely because we don't have a way to walk nodes in the heap (i.e. the standard C++ data structures only support pushing and popping). If we had a heap where we could walk nodes, I think it would simplify many of operations within the branch and bound code. Instead of popping a node off the heap, and tracking the lower bound, when solving, we could leave it on the heap and just mark that node as "solve in progress". We would only pop a node from the heap when the solve was completed. When trying to steal a node from a heap or dive from a node, thieves could avoid "solve in progress" nodes. Also, during a plunge we could push child nodes that we are not exploring directly onto the heap, instead of keeping them in a separate stack or circular buffer data structure.

If the code maintained the invariant that all open nodes are in a heap, I think it would be much easier to reason about the correctness of branch and bound.